Application programs are normally compiled from a fairly understandable source language program into a computer-specific object program, which object program may be understood by itself by only the most expert programmers. If the source language program is lost or misplaced, the object program can be patched only by someone who knows the principle of its working. But people die and move away. It is unarguable that many of today's most important programs are indecipherable as to principle, or algorithm.
It is basic to computers of the Von Neumann type, e.g., stored program type, that data can exist in boundaryless juxtaposition in the memory of such systems with other data, or even sections of the program. Existing data, new data, and the object program that operates upon them are an amorphous mix. The program itself may be recognized only by the sequence of its instructions.
The location of data in memory is known only by the addresses embedded in the program. With respect to the nature of the data itself, there are few clues. Without such clues it is impossible to distinguish a field containing the year portion of a date from any other pair of digit characters, or what instructions manipulate that field. Further, the proper execution of a program depends upon the finding of the correct data, not by name, not by descriptor, not by content, but by its relative position in the memory of the computer system executing the program.
The so-called millennium problem is the consequence of the history of development of digital computer systems which began in the 1940's, but which were not put into extensive use until the last half of the 20th century. Thus, from the beginning of the computer era to now, the millennium and the century have had constant digit values of 1 and 9. For convenience and to minimize size of memory required to execute such a program, the practice was to enter, to store, to perform arithmetic operations as required, and to output only two digits to represent the decade D and the year Y for the year value of a date. Reasons justifying this practice were that the sizes of the memories of early computer systems were relatively small, and their cost was very high. This practice is now a well-recognized problem, reportedly being worked on by many thousands of people.
The crux of the millennium problem is not that calendar year values are expressed in only two digit characters. It is rather that it is very difficult, when faced with a need to compute with and display them in a clearly recognizable form, such as in a 4-digit form, to recognize sans ambiguity a calendar year value, or calendar year increment value, hidden away in all that maze of existing data and instructions that consist only of 0's and 1's. Even if calendar year values were stored as 4 digit characters, how would one know "1990" to be a year value rather than a portion of a part number, a social security number, a vehicle I.D. code, a bar code identifier, a number of acres, an insurance policy number, a real estate deed number, a portion of a binary number (even floating point), etc. Barring source code change, as by the Picture Clause of COBOL, even entry of new year data as 4 digit characters does nothing to resolve this dilemma. Absent source code, the nature of data in memory may only be deduced via some limitations of the operations upon it.
One solution being pursued to solve the millennium problem is to detect the year value of dates of the source language version of the program, or of the object program if the source version is not available, and to modify the program so that the millennium and century digit characters, M and C, representing 1900 or 2000 are incorporated correctly in both program and its data descriptions. To do this, one has to search, or trace, through the program to find occurrences of numeric data and numeric data operations. Doing this by using Picture Clauses in source programs and then recompiling to a new object program is the optimum solution, albeit uncommon due to loss of much source code. Alternatively, one could replace all old code operating on date values with new code of a better method; e.g. one that always operates internally on dates in the Julian Day form. Unfortunately there does not seem to be time to implement either of these solutions before the year 2000 AD becomes a cause of failure.